home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Dynamo 4.2 for GSBug 1.5b10 / ! read.me next >
Encoding:
Text File  |  1990-09-21  |  5.9 KB  |  149 lines  |  [TEXT/MPS ]
  1. How to install Dynamo and do your first Dynamo build:
  2.  
  3.  
  4. 1)    Copy the Dynamo disk (or folder) contents into a folder called
  5.     "dynamo" on your hard disk.
  6.  
  7.  
  8. 2)    Make an addition to the "UserStartup" file for MPW.  This file is found
  9.     in the MPW folder itself.  You need to make an addition for Dynamo
  10.     something like the following:
  11.  
  12.     #   {dynamo} - Directory that contains dynamo package -- same level as MPW.
  13.                 set dynamo "{MPW}":dynamo:
  14.                 export dynamo
  15.  
  16. This example assumes that you created the Dynamo folder at the same directory
  17. level as MPW.  You can actually put it anywhere you want, as long as the
  18. location is reflected in the UserStartup file.
  19.  
  20.  
  21. 3)    Execute this addition to UserStartup, or restart MPW, so the UserStartup
  22.     addition can take effect.
  23.  
  24.  
  25. 4)    Issue the following duplicate command:
  26.  
  27.         duplicate -y "{dynamo}"dynamo.includes "{AIIGSIncludes}"
  28.  
  29.     You now have the Dynamo include files where AsmIIGS can find them.
  30.  
  31.  
  32. 5)    Copy the file called BUILDAPP.SYSTEM (in the app.builder directory) to
  33.     a ProDOS disk.  BUILDAPP.SYSTEM is a very useful program builder and
  34.     launcher for 8-bit applications.  See the "buildapp.manual" in the
  35.     "appbuilder" directory for details on "BUILDAPP.SYSTEM".
  36.     You can use the following command lines to copy BUILDAPP.SYSTEM to a
  37.     ProDOS disk:
  38.  
  39.         SetDirectory                "{Dynamo}"
  40.         duplicate -d                :app.builder:BUILDAPP.SYSTEM :app.builder:TEMP
  41.         setfile -c 'pdos' -t 'FF  ' :app.builder:TEMP
  42.         duplicateiigs -d -mac       :app.builder:TEMP BUILDAPP.SYSTEM
  43.         delete -y                   :app.builder:TEMP
  44.  
  45.  
  46. 6)    The Dynamo sample application should now be buildable.  Use the
  47.     following commands to set the current directory and copy the
  48.     buildapp.text script to your ProDOS disk.
  49.  
  50.         SetDirectory          "{Dynamo}"dynamo.sample:
  51.         duplicate -d          buildapp.text TEMP
  52.         duplicateiigs -d -mac TEMP BUILDAPP.TEXT
  53.         delete -y             TEMP
  54.  
  55.     The above duplicates are necessary due to an old bug in duplicateiigs
  56.     where the destination file was created with a resource fork if the
  57.     source file had one, even if you specified a data fork only copy.
  58.  
  59.  
  60. 7)    Now use the MPW menu command to do a full build.  The sample program
  61.     name is "sample" (surprise).  Once this is done, you will have a
  62.     ProDOS disk with everything necessary to execute the Dynamo sample
  63.     program.  Just double-click the BUILDAPP.SYSTEM if you are in the IIGS
  64.     finder, or if you have a IIe, then you will need to put ProDOS on the
  65.     disk as well, so it can boot.
  66.  
  67.  
  68. _________________________________________________________________________________
  69.  
  70.  
  71. Some new stuff and some cool ideas:
  72.  
  73. If you are familiar with previous versions of Dynamo, you will see that a
  74. number of things have changed and have been reorganized.  The structure is
  75. more conducive to multiple-project development.  Since Dynamo is localized
  76. and the include files are available to AsmIIGS just like other include files,
  77. Dynamo version control is easier.  It is no longer so tempting to make a
  78. simple custom change to the Dynamo ruuntime for just one application, and
  79. therefore end up with multiple versions of Dynamo for different projects.
  80.  
  81. Another big change is that the source code for BUILDAPP.SYSTEM is now
  82. included.  This is so that extensions in the application build and launch
  83. process can be done by others to better suit their needs.  Currently,
  84. BUILDAPP.SYSTEM simply moves the code to the bank and memory location
  85. described in the build script.  Some more complex methods might be needed
  86. for more complex applications.  An application may need overlays, for
  87. example.  There may be two blocks of code that actually need to run at
  88. the same location, just at different times.  A revised BUILDAPP.SYSTEM
  89. could put these so-designated segments in auxiliary memory, and then the
  90. application could move them to main memory when needed.
  91.  
  92. For example:  Here is a simple idea for an overlay system:
  93.  
  94. BUILDAPP.SYSTEM could move designated files to aux ram when it is moving
  95. segments around at application launch time.  This could even be done by
  96. using ProDOS to save the range of memory to /RAM5.  When the main
  97. application needs the code segment, it could simply use ProDOS to load it
  98. into main memory.
  99.  
  100. Here's a reasonably simple approach to overlays:  When you want to call
  101. a segment of code that may or may not be in main memory, do a jsr to 
  102. an overlay management routine.  (Dynamic segments kind of work this way
  103. on the IIGS.)  The code would look something like:
  104.  
  105.             sec                        ;Input for overlay code.
  106.             lda        value            ;Input for overlay code.
  107.             ldy        value+1            ;Input for overlay code.
  108.             ldx        mode            ;Input for overlay code.
  109.  
  110.             jsr        overlay
  111.             dc.b    jiffyCoolCode    ;Segment # we want to call.
  112.  
  113. The overlay manager would first save the registers and processor status.
  114. Then it would use the return address on the stack to figure out where the
  115. jiffyCoolCode segment number is in memory.  It would then get this byte
  116. from memory.  Once this is done, the return address would be incremented 
  117. by 1 and pushed back onto the stack.
  118.  
  119. Now that we have the overlay segment #, we would use this to load the
  120. segment from /RAM5.  Once it is loaded, the registers and processor status
  121. would be put back to what they were when the overlay manager was called.
  122. Once this is done, the overlay manager would jump to where the code was
  123. loaded.
  124.  
  125. A little more logic could be added to see if the code segment requested
  126. is already in main memory.  (Old segment # = requested segment #.)  If
  127. it is, then the loading of the code could be skipped.
  128.  
  129. As you can see, doing overlays isn't so tough after all.  A simple
  130. system like this can really free up a lot of main ram on an Apple II.
  131.  
  132. For more readibility, a macro could be used to call the overlay code.
  133. The call might look like:
  134.  
  135.             _jsr    jiffyCoolCode
  136.  
  137. The macro would expand to the calling convention shown above.
  138.  
  139.  
  140.  
  141. Any rate, given that BUILDAPP.SYSTEM isn't the final solution for
  142. everybody, I supplied the code so that everybody could change it
  143. if they wanted to.
  144.  
  145.  
  146.  
  147.  
  148. Eric Soldan, Apple II DTS
  149.